home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Power Programmierung
/
Power-Programmierung CD 2 (Tewi)(1994).iso
/
doc
/
qdpmi
/
qdpmi.qip
/
DPMIREAD.ME
next >
Wrap
Text File
|
1993-01-03
|
6KB
|
162 lines
QDPMI: Quarterdeck DPMI Host V1.01
=======
READ.ME
=======
QDPMI is an extension of Quarterdeck's QEMM-386
Memory Manager, and therefore requires that
QEMM-386 be installed before installation.
Quarterdeck's QDPMI V1.01 Host provides support
for the full DPMI 0.9 specification.
FILES IN THE 1.01 RELEASE:
==========================
1. LICENSE.TXT Quarterdeck Licensing
Agreement for QDPMI (only
included for BBS version).
2. INSTALL.EXE QDPMI Installation Program.
3 QDPMI.DOC On-line documentation for
QDPMI.
4. QDPMI.QIP Used by INSTALL.EXE. The
contents of QDPMI.QIP are:
A. QDPMI.SYS QDPMI 0.9 Host Device
Driver.
B. QDPMI.COM Control and status display
of QDPMI services.
C. QDPMIVM.OVL The QDPMI Kernel.
D. DPMIREAD.ME This file.
E. LWPFIX.COM Patch for Novell's LAN
WorkPlace v4.01 TCPIP.EXE
driver.
DIFFERENCES BETWEEN QDPMI 1.0 AND QDPMI 1.01?
=============================================
Version 1.01 of Quarterdeck's QDPMI 0.9 Host is
primarily a maintenance release. V1.01 is even
more compatible, and provides better
performance with existing commercial
applications that are DPMI clients.
There are a few new features found in V1.01,
however. They are summarized below:
Dynamic VM Swapfile growing:
============================
In QDPMI V1.0 when Virtual Memory was enabled,
a VM swapfile was created that equalled in size
the requested VM size specified in the QDPMI
environment variable. This could consume large
amounts of disk space, and slow down the
application. A couple of DPMI clients running
with 10 Megabyte swap files could fill up a
disk very quickly.
In QDPMI V1.01, the VM swapfile is created when
the DPMI client application starts up, but it
is created with a length of zero bytes. It is
grown as VM backing-store (swapfile pages) are
required. The file is never shrunk, except
when a DPMI client starts up, and at that time
it is truncated to zero length again. The
value specified in the QDPMI environment
variable is therefore the MAXIMUM size that
this file can ever become. It may never
actually reach that size, however. Its final
size depends entirely on how much memory the
DPMI client application allocates, and how much
physical memory is available at the time.
OVLDIR Command Line Parameter:
==============================
In some diskless workstation installations, the
drive letter of the boot device (the network)
is replaced after the boot process is
completed. QDPMI V1.0 required that the
QDPMIVM.OVL file be in the same directory as
QDPMI.SYS, which would not be possible if the
boot drive ceased to exist. QDPMI V1.01 allows
the user to specify the path to search when it
needs to load its QDPMIVM.OVL file. This may
be located on a device that is accessible at
the time a DPMI client starts up.
EMS AND DPMI MEMORY CONFLICTS:
==============================
QDPMI gets its memory resources through VCPI
memory services provided by QEMM. EMS also
shares this memory resource. Some DPMI clients
allocate both EMS and DPMI memory for their
use. When this happens, it is possible for
DPMI's memory resources to become depleted
without QDPMI's knowledge. If, for example,
DPMI services are asked to report how much free
memory is available, then all available EMS
memory is allocated, and finally some of the
DPMI memory reported to exist is allocated, the
DPMI allocation will either fail, or cause
QDPMI to begin swapping to disk if VM is
enabled. This can disconcerting on machines
with large amounts of physical memory.
There are two solutions to this problem.
First, if it is possible to limit the EMS usage
of the DPMI client application through the use
of command line switches or configuration
files, this should be done. Limiting EMS usage
to zero is recommended, as with QDPMI's VM, any
swapping can be handled by QDPMI.
If there is no way to accomplish this with the
client application, then setting QDPMI's MINMEM
parameter in the QDPMI environment variable to
be equal to the MAXMEM parameter will force
QDPMI to actually allocate ALL physical memory
it will ever use immediately when the DPMI
client application starts up. This will
prevent the client from allocating any EMS
because it will already be taken by QDPMI.
This tactic is basically doing to the client
application what it would try to do to us, and
beating it to the punch.
The latter suggestion is not encouraged in
multitasking environments, as it causes large
pieces system-wide memory resources to be
wasted.
Some programs known to exhibit this behavior
are:
1. Borland C/C++ 3.0 & 3.1. Use the
command line switch -Qe- to disable
EMS usage completely or -Qe=xxxx
where xxxx is a number of kilobytes
to allow to be allocated from EMS.
2. Microsoft C/C++ 7.0 Programmer's Work
Bench (PWB). Use the TOOLS.INI
mechanism to return EMS to the system
before shelling out to the individual
tools such as NMAKE, CL, and LINK.